test/unit/cli/context.test.js (1)

15-40: Add explicit tests for BIJOU_ACCESSIBLE and TERM=dumb branches.

Current coverage is good, but these two branches are part of mode precedence and worth locking with direct tests to prevent regressions.

Suggested test additions

 describe('detectCliTuiMode', () => {
+  it('uses accessible mode when BIJOU_ACCESSIBLE=1', () => {
+    const mode = detectCliTuiMode(makeRuntime({
+      env: { BIJOU_ACCESSIBLE: '1', TERM: 'xterm-256color' },
+    }));
+    expect(mode).toBe('accessible');
+  });
+
+  it('falls back to pipe when TERM is dumb', () => {
+    const mode = detectCliTuiMode(makeRuntime({
+      env: { TERM: 'dumb' },
+    }));
+    expect(mode).toBe('pipe');
+  });
+
   it('stays interactive on a TTY when NO_COLOR is set', () => {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/unit/cli/context.test.js` around lines 15 - 40, Add two explicit unit
tests for detectCliTuiMode: one that sets env BIJOU_ACCESSIBLE='1' (with TERM
present) and asserts the returned mode is the accessible mode (use
detectCliTuiMode with makeRuntime and expect mode === 'accessible' to lock that
branch), and another that sets TERM='dumb' (with a TTY stdout) and asserts the
returned mode is the static fallback (expect mode === 'static'); place them
alongside the existing tests so the BIJOU_ACCESSIBLE and TERM=dumb branches are
covered.

bin/ui/dashboard.js (1)

298-307: Tighten options.ctx contract for mode to avoid silent fallback.

Line 306 depends on ctx.mode, but Line 299 documents ctx as BijouContext. If a caller passes a plain BijouContext (no mode), this path always goes static (undefined !== 'interactive'). Consider normalizing or explicitly typing the injected context shape.

Suggested hardening

 /**
  * `@param` {ContentAddressableStore} cas
  * `@param` {{
- *   ctx?: BijouContext,
+ *   ctx?: (BijouContext & {
+ *     mode?: 'accessible' | 'pipe' | 'static' | 'interactive'
+ *   }),
  *   runApp?: typeof run,
  *   output?: Pick<NodeJS.WriteStream, 'write'>,
  * }} [options]
  */
 export async function launchDashboard(cas, options = {}) {
   const ctx = options.ctx || createCliTuiContext();
-  if (ctx.mode !== 'interactive') {
+  const mode = ctx.mode ?? 'interactive';
+  if (mode !== 'interactive') {
     return printStaticList(cas, options.output);
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@bin/ui/dashboard.js` around lines 298 - 307, The code relies on ctx.mode in
launchDashboard but accepts a plain BijouContext which may lack mode; update
launchDashboard to normalize/validate the injected context: if options.ctx is
provided but options.ctx.mode is undefined, either set ctx = { ...options.ctx,
mode: createCliTuiContext().mode } (or call createCliTuiContext() when mode is
missing) or explicitly throw a clear error so callers must pass a context with
mode. Locate the logic around launchDashboard, the options.ctx usage,
createCliTuiContext, and the branch that calls printStaticList and ensure
ctx.mode is always defined before comparing to 'interactive'.

CHANGELOG.md (1)

24-24: Changelog description doesn't fully match the actual code behavior.

The changelog states contexts without an explicit mode are treated "as interactive," but the implementation calls detectCliTuiMode() which returns one of four modes based on environment conditions:

• 'accessible' when BIJOU_ACCESSIBLE=1
• 'pipe' when TERM=dumb or non-TTY
• 'static' when CI env var is set
• 'interactive' as the default fallback

Consider rewording to something like: "now properly detects the mode for injected Bijou contexts without an explicit mode, avoiding an incorrect static fallback on real TTYs."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@CHANGELOG.md` at line 24, Update the changelog sentence to accurately reflect
the behavior of launchDashboard(): it doesn't unconditionally treat contexts
without mode as interactive but defers to detectCliTuiMode(), which can return
'accessible' (BIJOU_ACCESSIBLE=1), 'pipe' (TERM=dumb or non‑TTY), 'static' (CI
set), or 'interactive' as the fallback; rephrase to something like "now properly
detects the mode for injected Bijou contexts without an explicit mode (via
detectCliTuiMode()), avoiding an incorrect static fallback on real TTYs" and
mention the CLI tests lock BIJOU_ACCESSIBLE and TERM=dumb branches.

bin/ui/dashboard.js (1)

295-310: Consider adding a defensive guard for undefined runtime.

If an injected context lacks both mode and runtime, line 308 will call detectCliTuiMode(undefined), which may throw or produce unexpected results. While createCliTuiContext() guarantees a runtime (per context snippet 1), manually injected contexts in tests or future code may not.

This was flagged as a non-blocking concern in previous review comments. A minimal guard would make the contract explicit.

🛡️ Proposed defensive guard

 function normalizeLaunchContext(ctx) {
   const candidate = /** `@type` {BijouContext & { mode?: import('@flyingrobots/bijou').OutputMode }} */ (ctx);
   if (candidate.mode) {
     return candidate;
   }
+  if (!candidate.runtime) {
+    throw new TypeError('ctx.runtime is required when ctx.mode is absent');
+  }
   return {
     ...candidate,
     mode: detectCliTuiMode(candidate.runtime),
   };
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@bin/ui/dashboard.js` around lines 295 - 310, normalizeLaunchContext currently
assumes ctx.runtime exists and calls detectCliTuiMode(candidate.runtime), which
can misbehave if a context is injected without runtime; add a defensive guard in
normalizeLaunchContext to supply a safe default runtime (or undefined-safe
value) before calling detectCliTuiMode, e.g. check candidate.runtime and if
missing provide the same default runtime used by createCliTuiContext or return
candidate with a sensible mode (fallback) instead; update references in
normalizeLaunchContext and the call to detectCliTuiMode so tests and manual
injections don’t pass undefined.

test/unit/cli/dashboard.launch.default.test.js (1)

6-12: Consider extending mockCas to align with the actual CAS interface.

The mock only stubs three methods. If future tests exercise additional CAS methods, they'll fail silently with undefined. For a test helper, this is acceptable, but documenting the minimal interface or using a more complete stub could improve maintainability.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/unit/cli/dashboard.launch.default.test.js` around lines 6 - 12, The
mockCas helper currently only implements listVault, getVaultMetadata, and
readManifest which can cause future tests to fail if other CAS methods are
called; update mockCas to implement the fuller CAS interface used across the
codebase (at minimum add no-op/vi.fn().mockResolvedValue or mockRejectedValue
stubs for commonly used methods such as writeObject, readObject, deleteObject,
headObject, listObjects, and any metadata/update methods), keep the existing
entries parameter behavior, and document in the mockCas JSDoc comment which
methods are intentionally stubbed so callers know the minimal supported surface
(refer to mockCas, listVault, getVaultMetadata, readManifest when locating where
to add the extra stubs).

test/unit/cli/dashboard.launch.test.js (1)

38-53: Test implicitly depends on createTestContext runtime handling.

The test passes env as an object (line 42), but detectCliTuiMode calls runtime.env() as a function. This works because createTestContext presumably wraps the env object. If the test helper's behavior changes, this test could break silently.

Consider making the runtime explicit to decouple from helper internals:

Suggested explicit runtime

   it('treats an injected context without mode as interactive', async () => {
     const cas = mockCas();
+    const envMap = { TERM: 'xterm-256color' };
     const ctx = {
       ...makeCtx('interactive', {
-        env: { TERM: 'xterm-256color' },
+        env: (key) => envMap[key],
         stdoutIsTTY: true,
         stdinIsTTY: true,
       }),
     };

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/unit/cli/dashboard.launch.test.js` around lines 38 - 53, The test relies
on createTestContext's wrapping of env as a function, so update the injected
context passed to launchDashboard to provide the runtime shape detectCliTuiMode
expects: replace the plain env object with a runtime-like API (e.g., provide env
as a function or a runtime object with env() returning the env), and ensure
stdoutIsTTY/stdinIsTTY are set on that runtime or on the ctx the code reads;
modify the call site created by makeCtx/ctx so detectCliTuiMode sees
runtime.env() explicitly, avoiding implicit dependence on createTestContext
internals when calling launchDashboard and makeCtx.